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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee IMS Network Testing (INT). 

The present document is part 1 of a multi-part deliverable covering the IMS specific use of Session Initiation Protocol 
(SIP) and Session Description Protocol (SDP); Conformance Testing, as identified below: 

Part 1: "Protocol Implementation Conformance Statement (PICS)"; 

Part 2: "Test Suite Structure (TSS) and Test Purposes (TP)"; 

Part 3: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing (PIXIT) 
proforma specification". 



Introduction 



To evaluate protocol conformance of a particular implementation, it is necessary to have a statement of which 
capabilities and options have been implemented for a telecommunication specification. Such a statement is called a 
Protocol Implementation Conformance Statement (PICS). 
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Scope 



The present document provides the Protocol Implementation Conformance Statement (PICS) proforma for the IP 
Multimedia core network Subsystem (IMS) equipment supporting the Internet Protocol (IP) multimedia call control 
protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) as specified in 
TS 124 229 [1] in compliance with the relevant requirements and in accordance with the relevant guidance given in 
ISO/IEC 9646-7 [4] and ETS 300 406 [5]. 

The supplier of a protocol implementation which is claimed to conform to TS 124 229 [1] is required to complete a 
copy of the PICS proforma provided in annex A of the present document and is required to provide the information 
necessary to identify both the supplier and the implementation. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vahd at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 124 229 (VIO.7.0): "Digital cellular telecommunications system (Phase 2+); Universal 

Mobile Telecommunications System (UMTS); LTE; IP multimedia call control protocol based on 
Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP 
TS 24.229 version 10.7.0 Release 10)". 

[2] IETF RFC 3261 (2002): "SIP: Session Inifiafion Protocol". 

[3] ISO/IEC 9646-1: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 1: General concepts". 

[4] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[5] ETSI ETS 300 406: "Methods for testing and Specification (MTS); Protocol and profile 

conformance testing specifications; Standardization methodology". 

[6] IETF RFC 4412: "Communications Resource Priority for the Session Initiation Protocol (SIP)". 

[7] IETF RFC 5009: "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 

Authorization of Early Media". 

[8] ETSI TS 133 203: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; 3G security; Access security for IP-based services 
(3GPP TS 33.203)". 
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2.2 Informative references 



The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 124 229 [1] and the following apply: 

PICS proforma: document, in the form of a questionnaire, designed by the protocol specifier or conformance test suite 
specifier, which, when completed for an OSI implementation or system, becomes the PICS 

NOTE: See ISO/IEC 9646-1 [3]. 

Protocol Implementation Conformance Statement (PICS): statement made by the supplier of an Open Systems 
Interconnection (OSI) implementation or system, stating which capabilities have been implemented for a given OSI 
protocol 

NOTE: See ISO/IEC 9646-1 [3]. 

static conformance review: review of the extent to which the static conformance requirements are met by the lUT, 
accomplished by comparing the PICS with the static conformance requirements expressed in the relevant standard(s) 

NOTE: See ISO/IEC 9646-1 [3]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TS 124 229 [1] apply. 



Conformance 



A PICS proforma which conforms to this PICS proforma specification shall be technically equivalent to annex A, and 
shall preserve the numbering and ordering of the items in annex A. 

A PICS which conforms to this PICS proforma specification shall: 

a) describe an implementation which claims to conform to TS 124 229 [1]; 

b) be a conforming ICS proforma which has been completed in accordance with the instructions for completion 
given in clause A. 1 ; 

c) include the information necessary to uniquely identify both the supplier and the implementation. 
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Annex A (normative): 
PICS proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the PICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed PICS. 



A.1 Guidance for completing the ICS proforma 



A.1 .1 Purposes and structure 



The purpose of this PICS proforma is to provide a mechanism whereby a supplier of an implementation of the 
requirements defined in relevant specifications may provide information about the implementation in a standardised 
manner. 

The PICS proforma is subdivided into clauses for the following categories of information: 

instructions for completing the PICS proforma; 

identification of the implementation; 

identification of the protocol; 

PICS proforma tables (for example: Major capabilities, etc). 

A.1 .2 Abbreviations and conventions 

This annex does not reflect dynamic conformance requirements but static ones. In particular, a condition for support of 
a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) but the 
capability of the implementation to support the parameter. 

In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it 
does not mean that the implementation always sends it). 

In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is 
described in the main part of the present document. 

As a consequence, PDU parameter tables in this annex are not the same as the tables describing the syntax of a PDU in 
the reference specification. 

The PICS proforma contained in this annex is comprised of information in tabular form in accordance with the 
guidelines presented in ISO/IEC 9646-7 [4]. 

Item column 

The item column contains a number which identifies the item in the table. 

Item description column 

The item description column describes in free text each respective item (e.g. parameters, timers, etc.). It implicitly 
means "is <item description> supported by the implementation?". 

Reference column 

The reference column gives reference to the relevant sections in core specifications. 
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Status column 

The various status used in this annex are in accordance with the rules in table A.l. 

Table A.l : Key to status codes 



Status code 


Status name 


Meaning 


m 


mandatory 


The capability shall be supported. It is a static view of the fact that the 
conformance requirements related to the capability in the reference 
specification are mandatory requirements. This does not mean that a given 
behaviour shall always be observed (this would be a dynamic view), but that it 
shall be observed when the implementation is placed in conditions where the 
conformance requirements from the reference specification compel it to do so. 
For instance, if the support for a parameter in a sent PDU is mandatory, it does 
not mean that it shall always be present, but that it shall be present according 
to the description of the behaviour in the reference specification (dynamic 
conformance requirement). 





optional 


The capability may or may not be supported. It is an implementation choice. 


n/a 


not applicable 


It is impossible to use the capability. No answer in the support column is 
required. 


c.<integer> 


conditional 


The requirement on the capability ("m", "o" and "n/a") depends on the support 
of other optional or conditional items. <integer> is the identifier of the 
conditional expression. 


o.<integer> 


qualified optional 


For mutually exclusive or selectable options from a set. <integer> is the 
identifier of the group of options, and the logic of selection of the options. 



Mnemonic column 

The Mnemonic column contains mnemonic identifiers for each item. 

Support column 

The support column shall be filled in by the supplier of the implementation. The following common notations, defined 
in ISO/IEC 9646-7 [4], are used for the support column: 



Y or y 
N or n 



supported by the implementation 
not supported by the implementation 



N/A, n/a or- no answer required (allowed only if the status is N/A, directly or after evaluation of a 

conditional status) 

References to items 

For each possible item answer (answer in the support column) within the PICS proforma there exists a unique reference, 
used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", 
followed by the item number in the table. 



EXAMPLE: 



A. 5/4 is the reference to the answer of item 4 in table A. 5. 



A.1 .3 Instructions for completing the PICS proforma 

The supplier of the implementation may complete the PICS proforma in each of the spaces provided. More detailed 
instructions are given at the beginning of the different clauses of the PICS proforma. 
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A.2 Identification of the Network Equipment 

Identification of the Network Equipment should be filled in so as to provide as much detail as possible regarding 
version numbers and configuration options. 

The product supplier information and client information should both be filled in if they are different. 

A person who can answer queries regarding information supplied in the PICS should be named as the contact person. 



A.2.1 Date of the statement 



A.2. 2 Network Equipment Under Test identification 

Name: 



Hardware configuration: 



Software configuration: 



A.2. 3 Product supplier 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 
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Additional information: 



A.2.4 Client 

Name: 



Address: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 



A.2.5 PICS contact person 

Name: 



Telephone number: 



Facsimile number: 



E-mail address: 



Additional information: 
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A.3 Identification of the protocol 

This PICS proforma applies to the following specification: 
TS 124 229 [1]. 



A. 4 Global statement of conformance 

The implementation described in this PICS meets all the mandatory requirements of the referenced standard? 



[ ] Yes 



[ ]No 



NOTE: Answering "No" to this question indicates non-conformance to the protocol specification. Non-supported 
mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is 
non-conforming. Explanations may be entered in the comments field at the bottom of each table or on 
attached pages. 

In the tabulations which follow, all references are to TS 124 229 [1] unless another numbered reference is explicitly 
indicated. 



A.5 PICS proforma tables 



A.5.1 Roles 



Table A.2: Roles 



Item 


Roles 


Reference 


Status 


Support 


1 


P-CSCF 


Clause 5.2 


0.1 




2 


l-CSCF 


Clause 5.3 


0.1 




3 


S-CSCF 


Clause 5.4 


0.1 




4 


IBCF 


Clause 5.10 


0.1 




5 


E-CSCF 


Clause 5.11 


0.1 




0.1 At least one of these capabilities shall be supported. 



A.5.2 P-CSCF Role 

The tables provided in this clause need only to be completed for P-CSCF implementations, where item A. 2/1 above is 
supported. 
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A.5.2.1 P-CSCF Capabilities 



Table A.3: P-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


The proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.2 


m 




1.2 


The proxy role with IIVIS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.2 


m 




1.3 


The proxy role with IMS related exceptions and 
additional capabilities to SigComp? 


Clauses 4.1, 8.2 


m 




2 


the UA role in providing application level gateway functionality (IMS-ALG) (clause 4.1 ) ... 


2.1 


... for subscribing to or the receiving of event 
information? 


Clauses 4.1, 5.2 


m 




2.2 


... for performing P-CSCF initiated dialog-release? 


Clauses 4.1, 5.2 


m 




2.3 


... for performing NAT traversal procedures? 


Clause 4.1, 
annexes F, G, K 


m 




2.4 


... for performing media plane security procedures? 


Clauses 4.1, 5.2 


m 




3 


The access technology specific procedures? 


Clauses 4.1, 3A, 
9.2.2 


m 




4 


signalling security using (Clause 4.2B.1) ... 


4.1 


IMS AKA plus IPsec ESP? 


Clauses 4.2B.1, 
table 4-1, 
TS 133 203 [8], 
clause 6 


m 




4.2 


SIP digest plus check of IP association? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 8], 
annex S 







4.3 


SIP digest plus Proxy Authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8], 
annex N 







4.4 


SIP digest with TLS? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8], 
annexes N, 







4.5 


NASS-IMS bundled authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 1 33 203 [8] 
annex R 







4.6 


GPRS-IMS-Bundled authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8], 
annex S 







5 


End-to-access-edge media security using SDES? 


Clause 4.2B.2, 
table 4-2 


m 




6.1 


The loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




6.2 


Interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] 
Clauses 12.2.1.1, 
16.4 


m 




7 


Procedures related to charging? 


Clause 4.5 


m 




8 


Procedures related to emergency services? 


Clauses 4.7, 5.2.10 


m 




9 


Tracing of signalling? 


Clause 4.8 







10 


Priority mechanisms? 


Clause 4.11 


m 




P-CSCF specific application usage of SIP (clause 5.2) 


11 


Provision of priority to emergency and priority 
transactions? 


Clause 5.2.1 


m 




Registration general (clause 5.2. 1) 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


12.1 


Selection of the security mechanism based on the 
content of the REGISTER request (Security-Client 
header field and the Require and Proxy-Require 
header fields set to "sec-agree") received from the 
UE? 


Clause 5.2.2.1, first 
numbered list item 1 


m 




12.2 


Selection of the security mechanism based on the 
access type when the REGISTER request 
received from the UE does not contain a 
Security-Client header field, or contains a 
Security-Client header field and the Require and 
Proxy-Require header fields do not contain 
"sec-agree"? 


Clause 5.2.2.1, first 
numbered list item 2 


m 




13 


General procedures that apply on receipt of a 
REGISTER request from the UE? 


Clause 5.2.2.1, 
second numbered 
list 


m 




14 


General procedures that apply on receipt of a 
200OK response to a REGISTER request? 


Clause 5.2.2.1, third 
numbered list 


m 




Registration wiien /MS AKA as a security mechanism appiies (ciause 5.2.2) 


15.1 


Specific procedures that apply on receipt of a 
unprotected REGISTER request from the UE 
when IIVIS AKA as a security mechanism applies? 


Clause 5.2.2.2, first 
numbered list 
items 1, 2 


m 




15.2 


Specific procedures that apply on receipt of a 
protected REGISTER request from the UE when 
IIVIS AKA as a security mechanism applies? 


Clause 5.2.2.2, first 
numbered list 
items 1, 3 


m 




15.2.1 


Rejection of the protected REGISTER request in 
case of failure of the verification of the content of 
the Security-Verify headers and Security-Client 
headers? 


Clause 5.2.2.2, 
first numbered list 
item 3 a) 







15.3 


Procedures that apply on receipt of a 401 
response to a (unprotected) REGISTER request? 


Clause 5.2.2.2, 
second numbered 
list 


m 




15.4 


Procedures that apply on receipt of a 200OK 
response to a (protected) REGISTER request? 


Clause 5.2.2.2, third 
numbered list 


m 




15.5 


Parallel management of old and newly established 
security associations? 


Clause 5.2.2.2, 
fourth and fifth 
numbered lists, 
table 5.2.2-1 


m 




Registration wittiout TLS as a security meclianism (ciause 5.2.3) 


16.1 


Specific procedures that apply on receipt of a 
REGISTER request from the UE when no TLS 
security mechanism applies? 


Clause 5.2.2.3, first 
numbered list 


m 




16.2 


Procedures that apply on receipt of a 500 
response to a REGISTER request? 


Clause 5.2.2.3 


m 




16.3 


Procedures that apply on receipt of a 200OK 
response to a REGISTER request? 


Clause 5.2.2.3, first 
alphabetic list 


m 




Registration when TLS as a security mechanism appiies (clause 5.2.2.4) 


17 


TLS as a security mechanism? 


Clause 5.2.2.4 







17.1 


Specific procedures that apply on receipt of a 
unprotected REGISTER request from the UE 
when TLS as a security mechanism applies? 


Clause 5.2.2.4, first 
numbered list 
items 1 


C.1 




17.2 


Specific procedures that apply on receipt of a 
protected REGISTER request from the UE when 
IIVIS AKA as a security mechanism applies? 


Clause 5.2.2.4, first 
numbered list item 2 


C.1 




17.2.1 


Rejection of the protected REGISTER request in 
case of failure of the verification of the content of 
the Security-Verify headers and Security-Client 
headers? 


Clause 5.2.2.4, first 
numbered list 
items 2 b) and 3 b) 


C.2 




17.3 


Procedures that apply on receipt of a 401 
response to a (unprotected) REGISTER request? 


Clause 5.2.2.4, 
second numbered 
list 


c.1 




17.4 


Procedures that apply on receipt of a 200OK 
response to a (protected) REGISTER request? 


Clause 5.2.2.4, 
dashed list 


c.1 




Registration when NASS-iMS bundied authentication as a security mechanism appiies (ciause 5.2.2.5) 


18.1 


Specific procedures that apply on receipt of a 
request from the UE when NASS-IIVIS bundled 


Clause 5.2.2.5, 
numbered list 


m 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 




authentication as a security mechanism applies? 








18.2 


Procedures that apply on receipt of a 200OK 
response to a REGISTER request? 


Clause 5.2.2.5, 
alphabetic list 


m 




Registration wtien GPRS-liVIS bundied auttientication as a security mectianism applies (clause 5.2.2.6) 


19.1 


Specific procedures that apply on receipt of a 
REGISTER request from the UE when GPRS-IMS 
bundled authentication as a security mechanism 
applies? 


Clause 5.2.2.6 


m 




19.2 


Procedures that apply on receipt of a 200OK 
response to a REGISTER request? 


Clause 5.2.2.6, 
numbered list 


m 




Subscription, registration of additional identities, de-registration(clauses 5.2.3 - 5.2.5) 


20 


Subscription procedures to a user's registration 
state event package? (see note 1) 


Clause 5.2.3 


m 




21 


Subscription procedures to a user's debug event 
package? (see note 2) 


Clause 5.2.3A 


m 




22 


Procedures of registering additional public user 
identities? (see note 3) 


Clause 5.2.4 


m 




23.1 


Procedures for user-initiated deregistration? 


Clause 5.2.5.1 


m 




23.2 


Procedures for network-initiated deregistration? 


Clause 5.2.5.2 


m 




Handling of requests other than REGISTER (clause 5.2.6) 


Requests initiated by the UE (clause 5.2.6.3) 


24.1 


General handling of initial requests for a dialog or 
requests for a standalone transaction from a UE? 


Clause 5.2.6.3.1 


m 




24.1.1 


Handling of initial request for a dialog or a request 
for a standalone transaction from a UE that is not 
considered as privileged sender? 


Clause 5.2.6.3.1 
dashed list 


m 




24.1.2 


Handling of initial request for a dialog or a request 
for a standalone transaction from a UE that is 
considered as privileged sender? 


Clause 5.2.6.3.1 
alphabetic and 
numbered list 


m 




24.2 


General handling of responses from a UE? 


Clause 5.2.6.3.2 


m 




24.3 


Rejection of requests with restoration procedures? 


Clause 5.2.6.3.2A 







24.4 


Handling of initial requests for a dialog? 


Clause 5.2.6.3.3 


m 




24.4.1 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3.3 item 2)) ... 


24.4.1.1 


Rejection of the request? 


Clause 5.2.6.3.3 
item 2) a) 


0.1 




24.4.1.2 


Replacement of the Route headers with stored 
values? 


Clause 5.2.6.3.3 
item 2) b) 


0.1 




24.4.2 


When building the Via header (clause 5.2.6.3.3 item 4)) ... 


24.4.2.1 


Insertion of the P-CSGF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3.3 
item 4) a) 


0.2 




24.4.2.2 


Insertion of the P-CSGF IP address? 


Clause 5.2.6.3.3 
item 4) b) 


0.2 




24.4.3 


When building the Record-Route header (clause 5.2.6.3.3 item 5)) ... 


24.4.3.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address? 


Clause 5.2.6.3.3 
item 5) a) 


0.3 




24.4.3.2 


Insertion of the P-CSCF IP address? 


Clause 5.2.6.3.3 
item 5) b) 


0.3 




24.5 


Handling of Ixx and 2xx responses to initial 
requests? 


Clause 5.2.6.3, 
second numbered 
list 


m 




24.5.1 


In case a security association or a TLS session exists, when rewriting its own Record Route entry 
(clause 5.2.6.3.4 item 4)) ... 


24.5.1.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or the TLS 
session? 


Clause 5.2.6.3.4 
item 4) a) 


0.4 




24.5.1.2 


Insertion of the P-CSCF IP address of the security 
association or the TLS session? 


Clause 5.2.6.3.4 
item 4) b) 


0.4 




24.6 


Handling of target refresh requests? 


Clause 5.2.6.3.5 


m 




24.6.1 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3.5 item 2)) ... 


24.6.1.1 


Rejection of the request? 


Clause 5.2.6.3.5 
item 2) a) 


0.5 




24.6.1.2 


Replacement of the Route headers with stored 
values? 


Clause 5.2.6.3.5 
item 2) b) 


0.5 




24.6.2 


When building the Via header (clause 5.2.6.3.5 item 3)) ... 


24.6.2.1 


Insertion of the P-CSCF FQDN that resolves to the |Clause 5.2.6.3.5 | 0.6 | 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 




IP address? 


item 3) a) 






24.6.2.2 


Insertion of the P-CSCF IP address? 


Clause 5.2.6.3.5 
item 3) b) 


0.6 




24.7 


Handling of responses to target refresh requests? 


Clause 5.2.6.3.6 


m 




24.8 


Handling of requests for a standalone transaction? 


Clause 5.2.6.3.7 


m 




24.8.1 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3 item 2)) ... 


24.8.1.1 


Rejection of the request? 


Clause 5.2.6.3.7 
item 2) a) 


0.7 




24.8.1.2 


Replacement of the Route headers with stored 
values? 


Clause 5.2.6.3.7 
item 2) b) 


0.7 




24.9 


Handling of responses to standalone requests? 


Clause 5.2.6.3.8 


m 




24.10 


Handling of subsequent (other than target refresh) 
requests? 


Clause 5.2.6.3.9 


m 




24.10.1 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3.9 item 2)) ... 


24.10.1.1 


Rejection of the request? 


Clause 5.2.6.3.9 
item 2) a) 


0.8 




24.10.1.2 


Replacement of the Route headers with stored 
values? 


Clause 5.2.6.3.9 
item 2) b) 


0.8 




24.11 


Handling of requests for unknown method that do 
not relate to an existing dialog? 


Clause 5.2.6.3.11 


m 




24.11.1 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.3.11 item 1)) ... 


24.11.1.1 


Rejection of the request? 


Clause 5.2.6.3.11 
item 1) a) 


0.9 




24.11.1.2 


Replacement of the Route headers with stored 
values? 


Clause 5.2.6.3.11 
item 1) b) 


0.9 




Requests terminated by the UE (clause 5.2.6.4) 


25.1 


General handling of initial requests for a dialog or 
requests for a standalone transaction terminated 
bytheUE? 


Clause 5.2.6.4.1 


m 




25.2 


General handling of responses destined to a UE? 


Clause 5.2.6.4.2 


m 




25.3 


Handling of initial requests for a dialog destined for 
aUE? 


Clause 5.2.6.4.3 


m 




25.3.1 


When building the Record-Route header (clause 5.2.6.4.3 item 4)) ... 


25.3.1.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.3 
item 4) a) 


O.10 




25.3.1.2 


Insertion of the P-CSCF IP address of the security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4.3 
item 4) b) 


O.10 




25.3.2 


When building the Via header (clause 5.2.6.4.3 item 6)) ... 


25.3.2.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.3 
item 6) a) 


0.11 




25.3.2.2 


Insertion of the P-CSCF IP address of the security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4.3 
item 6) b) 


0.11 




25.4 


Handling of Ixx and 2xx responses to initial 
requests? 


Clause 5.2.6.4.4 


m 




25.4.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.4 item 2)) . . . 


25.4.1.1 


Discarding the response? 


Clause 5.2.6.4.4 
item 2) a) 


0.12 




25.4.1.2 


Replacement of the Via header values with stored 
values? 


Clause 5.2.6.4.4 
item 2) b) 


0.12 




25.4.2 


In case of failure of the verification of the URIs in the Route headers (clause 5.2.6.4.4 item 3)) ... 


25.4.2.1 


Discarding the response? 


Clause 5.2.6.4.4 
item 3) first a) 


0.13 




25.4.2.2 


Replacement of the Record-Route header values 
with stored values? 


Clause 5.2.6.4.4 
item 3) first b) 


0.13 




25.4.2.2 


When replacing build the Record-Route header with (clause 5.2.6.4.4 item 3) first b)) ... 


25.4.2.2.1 


The P-CSCF FQDN that resolves to its IP 
address? 


Clause 5.2.6.4.4 
item 3) first b) 


C.I 




25.4.2.2.2 


The P-CSCF IP address? 


Clause 5.2.6.4.4 
item 3) first b) 


C.I 




25.4.3 


When building the Record-Route header in case of success of the verification of the URIs in the Route 
headers (clause 5.2.6.4.4 item 3) second alphabetic list) ... 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


25.4.3.1 


The P-CSCF FQDN that resolves to its IP 
address? 


Clause 5.2.6.4.4 
item 3) second a) 


0.14 




25.4.3.2 


The P-CSCF IP address? 


Clause 5.2.6.4.4 
item 3) second b) 


0.14 




25.5 


Handling of responses (other than Ixx and 2xx) to 
initial requests? 


Clause 5.2.6.4, third 
numbered list 


m 




25.5.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.4 third alphabetic list) ... 


25.5.1.1 


Discarding the response? 


Clause 5.2.6.4.4 
third a) 


0.15 




25.5.1.2 


Replacement of the Via header values with stored 
values? 


Clause 5.2.6.4.4 
third b) 


0.15 




25.6 


Handling of target refresh requests? 


Clause 5.2.6.4.5 


m 




25.6.1 


When building the Via header (clause 5.2.6.4.5 item 1)) ... 


25.6.1.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.5 
item 1) a) 


0.16 




25.6.1.2 


Insertion of the P-CSCF IP address of the security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4.5 
item1)b) 


0.16 




25.6.2 


When building the Record-Route header (clause 5.2.6.4.5 item 3)) ... 


25.6.2.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.5 
item 3) a) 


0.17 




25.6.2.2 


Insertion of the P-CSCF IP address of the security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4.5 
item 3) b) 


0.17 




25.7 


Handling of 1xx and 2xx responses to target 
refresh requests? 


Clause 5.2.6.4.6, 
first numbered list 


m 




25.7.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.6 first 1 )) . . . 


25.7.1.1 


Discarding the response? 


Clause 5.2.6.4.6 
first 1) a) 


0.18 




25.7.1.2 


Replacement of the Via header values with stored 
values? 


Clause 5.2.6.4.6 
first 1)b) 


0.18 




25.8 


Handling of responses (other than Ixx and 2xx) to 
target refresh requests? 


Clause 5.2.6.4.6, 
second numbered 
list 


m 




25.8.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.6 second 1 )) . . . 


25.8.1.1 


Discarding the response? 


Clause 5.2.6.4 
second 1) a) 


0.19 




25.8.1.2 


Replacement of the Via header values with stored 
values? 


Clause 5.2.6.4 
second 1) b) 


0.19 




25.9 


Handling of requests for standalone transactions or 
unknown methods? 


Clause 5.2.6.4.7 


m 




25.9.1 


When building the Via header (clause 5.2.6.4.7 item 2)) ... 


25.9.1.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.7 
item 2) a) 


0.2G 




25.9.1.2 


Insertion of the P-CSCF IP address of the security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4 
item 2) b) 


O.20 




25.10 


Handling of all responses to requests for 
standalone transactions or unknown methods? 


Clause 5.2.6.4.8 


m 




25.10.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.8 item 1 )) . . . 


25.10.1.1 


Discarding the response? 


Clause 5.2.6.4.8 
item 1) a) 


0.21 




25.10.1.2 


Replacement of the Via values with stored values? 


Clause 5.2.6.4.8 
item 1) b) 


0.21 




25.11 


Handling of subsequent (other than target refresh) 
requests? 


Clause 5.2.6.4.9 


m 




25.11.1 


When building the Via header (clause 5.2.6.4.9 item 1)) ... 


25.11.1.1 


Insertion of the P-CSCF FQDN that resolves to the 
IP address of the security association or TLS 
session established from the UE to the P-CSCF? 


Clause 5.2.6.4.9 
item 1) a) 


0.22 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


25.11.1.2 


insertion of the P-CSCF IP address of tlie security 
association or TLS session established from the 
UE to the P-CSCF? 


Clause 5.2.6.4.9 
item 1) b) 


0.22 




25.12 


Handling of Ixx and 2xx responses to subsequent 
requests? 


Clause 5.2.6.4.10 


m 




25.12.1 


In case of failure of the verification of the Via headers (clause 5.2.6.4.10 item 1)) ... 


25.12.1.1 


Discarding the response? 


Clause 5.2.6.4.10 
item 1) a) 


0.23 




25.12.1.2 


Replacement of the Via header values with stored 
values? 


Clause 5.2.6.4.10 
item 1) b) 


0.23 




Additional requirements for INVITE Request, session termination and subsequent requests (clauses 5.2.7, 5.2.8, 5.2.9) 


26.1 


Additional requirements for UE-originated INVITE 
requests? 


Clause 5.2.7.2 


m 




26.1.1 


Application of periodic session refreshment on 
receipt of UE-originated INVITE requests? 


Clause 5.2.7.2 







26.2 


Additional requirements for UE-terminated INVITE 
requests? 


Clause 5.2.7.3 


m 




26.2.1 


Application of periodic session refreshment on 
receipt of UE-terminated INVITE requests? 


Clause 5.2.7.3 







27.1 


P-CSCF initiated call release (clause 5.2.8.1 ) ... 


27.1.1 


Cancellation of a session currently being 
established? 


Clause 5.2.8.1.1 


m 




27.1.2 


Release of an existing session? 


Clause 5.2.8.1.2 


m 




27.2 


Call release initiated by other entities? 


Clause 5.2.8.2 


m 




27.3 


Call release due to session expiry? 


Clause 5.2.8.3 


m 




28.1 


Additional requirements for subsequent requests 
(UE-originating case)? 


Clause 5.2.9.1 


m 




28.2 


Additional requirements for subsequent requests 
(UE-terminating case)? 


Clause 5.2.9.2 


m 




Emergency service (clause 5.2. 10) (see note 4) 


29.1 


Handling of emergency session establishment 
within a non-emergency registration? 


Clause 5.2.10.1 


m 




29.2 


Emergency registrations? 


Clause 5.2.10.1 


m 




29.3 


Requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
unregistered user? 


Clause 5.2.10.2 


m 




29.3.1 


When building the URI (clause 5.2.10.2 item 1)) ... 


29.3.1.1 


Inclusion of the URI received from the UE? 


Clause 5.2.10.2 
item 1) first dash 


0.24 




29.3.1.2 


Inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.2 
item 1) second dash 


0.24 




29.4 


Delivery of responses for all dialogs and 
standalone transactions (other than REGISTER) to 
an unregistered user? 


Clause 5.2.10.2 


m 




29.5 


Treatment for all dialogs and standalone 
transactions (other than REGISTER) related to 
requests to an unregistered user? 


Clause 5.2.1 0.2.A 


m 




29.6 


Requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
emergency-registered user? 


Clause 5.2.10.3 


m 




29.6.1 


When building the URI (clause 5.2.10.3 item 1)) ... 


29.6.1.1 


Inclusion of the URI received from the UE? 


Clause 5.2.10.3 
item 1) first dash 


0.25 




29.6.1.2 


Inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.3 
item 1) second dash 


0.25 




29.7.1 


Requests for all dialogs and standalone 
transactions (other than REGISTER) from an 
non-emergency-registered user? 


Clause 5.2.10.4 


m 




29.7.1.1 


When building the URI (clause 5.2.10.4 item 1)) ... 


29.7.1.1.1 


Inclusion of the URI received from the UE? 


Clause 5.2.10.4 
item 1) first dash 


0.26 




29.7.1.1.2 


Inclusion of a URI deduced from the URI received 
from the UE? 


Clause 5.2.10.4 
item 1) second dash 


0.26 




29.8 


Abnormal and rejection cases? 


Clause 5.2.10.5 


m 




P-CSCF specific application usage of SDP (clause 6.2) 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


30.1 


Handling of requests including SDP offers? 


Clause 6.2 second 
and third paragraphs 


m 




30.1.1 


Rejection of requests including encrypted SDP 
offers? 


Clause 6.2, third 
paragraph 







30.2 


Handling of responses (other than 200OK) 
including SDP offers? 


Clause 6.2, fifth 
paragraph 


m 




30.2.1 


Rejection of requests following non-200OK 
responses including encrypted SDP offers? 


Clause 6.2, fifth 
paragraph 







30.3 


Handling of 200OK responses including SDP 
offers? 


Clause 6.2, sixth 
paragraph 


m 




30.3.1 


Session termination on receipt of encrypted SDP 
offers in 200OK responses? 


Clause 6.2, sixth 
paragraph 







30.4 


Inspection of b=RS and b=RR lines within an SDP 
offer? 


Clause 6.2, ninth 
paragraph 







IMS-ALG in P-CSCF (clause 6. 7.2) 


31 


IIVIS-ALG functionality within the P-CSCF? 


Clause 6.7.2 







31.1 


General procedures for the support of SDP in 
IMS-ALG within the P-CSCF? 


Clause 6.7.2.1 


C.2 




31.2 


ilVlS-ALG in P-CSCF procedures for media plane 
security? 


Clause 6.7.2.2 


C.2 




31.3 


IIVIS-ALG in P-CSCF procedures for explicit 
congestion control support? 


Clause 6.7.2.3 


c.2 




31.4 


IMS-ALG in P-CSCF procedures for Optimal Media 
Routeing (OMR)? 


Clause 6.7.2.4 


c.2 




31.5 


IMS-ALG in P-CSCF procedures for NA(P)T and 
NA(P)T-PT controlled by the P-CSCF? 


Clause 6.7.2.5 


c.2 




31.6 


IMS-ALG in P-CSCF procedures for support of 
hosted NAT? 


Clause 6.7.2.6 


c.2 




31.7 


IMS-ALG in P-CSCF procedures for support of 
ICE? 


Clause 6.7.2.7 


c.2 




31.8 


IMS-ALG in P-CSCF procedures for transcoding? 


Clause 6.7.2.8 


c.2 




SIP compression (clause 8.2) 


32 


SIP compression? 


Clauses 8.2.1, 8.2.2 


m 




32.1 


The negative acknowledgement mechanism for 
compression? 


Clause 8.2.1 







32.3 


The presence specific dictionary for compression? 


Clause 8.2.1 







32.4 


Compression of requests and responses to a UE? 


Clause 8.2.2 







32.4 


Decompression of requests and responses from a 
UE? 


Clause 8.2.3 


m 




IP-Connectivity Access Network specific concepts when using GPRS to access IM CN subsystem (Annex B) 


33 


Application usage of SIP when using GPRS to 
access IM CN subsystem? 


Clause B.3.2 


m 




IP-Connectivity Access Network specific concepts when using xDSL to access IM CN subsystem (Annex E) 


34 


Application usage of SIP when using xDSL access 
to IM CN subsystem? 


Clause E.3.2 


m 




34.1 


Insertion of the P-Access-Network-lnfo header 

for location information handling? 


Clause E.3.2.2 







Additional procedures in support for hosted NA T (Annex F) 


35 


Additional procedures in support for hosted NAT? 


Annex F 







35.1 


Usage of SIP in support for hosted NAT? 


Clause F.2.2 


C.3 




35.1.1 


Rejection of integrity protected REGISTER 
requests in case the comparison of the 
Security-Verify header and the Security-Server 
header with stored values fails? 


Clause F.2.2, 

item (3 (b, third dash 







35.2 


Usage of SIP in support for hosted NAT in case 
UDP encapsulated IPsec is not employed? 


Clause F.4 


c.3 




IP-Connectivity Access Network specific concepts when using DOCSIS to access IM CN subsystem (Annex H) 


36 


Usage of SIP when DOCSIS to access to the IM 
CN subsystem was requested? 


Clause H.3.2 


m 




36.1 


Insertion of the P-Access-Network-lnfo header 

for location information handling? 


Clause H.3.2.2 







Additional procedures in support of UE managed NA T traversal (Annex K) 


37 


Application usage of SIP for UE managed NAT 
traversal? 


Clause K.2.2 


m 





£75/ 



19 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


37.1 


Additional procedures to registration with security 
association set-up for UE managed NAT traversal? 


Clause K.2.2.2 


m 




37.2 


Additional procedures to handling of requests 
(other than REGISTER) initiated or terminated by a 
UE for UE managed NAT traversal? 


Clause K.2.2.3 


m 




37.3 


Additional procedures to the emergency service for 
UE managed NAT traversal? 


Clause K.2.2.5 


m 




38 


Application usage of SDP for UE managed NAT 
traversal? 


Clause K.3.2 


m 




39 


Application usage of ICE for UE managed NAT 
traversal? 


Clause K.5.3 


m 




IP-Connectivity Access Networl< specific concepts wlien using EPS to access IM CN subsystem (Annex L) 


40 


Application usage of SIP when using EPS access 
to IM CN subsystem? 


Clause L.3.2 


m 




IP-Connectivity Access Network specific concepts when using cclma200(f packet data subsystem to access liVI CN 
subsystem (Annex M) 


41 


Application usage of SIP when using cdma2000® 
packet data subsystem access to IM CN 
subsystem? 


Clause M.3.2 


m 




IP-Connectivity Access Network specific concepts when using the EPC via cdma2000® HRPD to access IM CN 
subsystem (Annex 0) 


42 


Application usage of SIP when using the EPC via 
cdma2000® HRPD access to IM CN subsystem? 


Clause 0.3.2 


m 




IP-Connectivity Access Network specific concepts when using cdma2000® 1x Femtoceli Network to access IM CN 
subsystem (Annex Q) 


43 


Application usage of SIP when using cdma2000'* 
1x Femtoceli Networl< access to IM CN 
subsystem? 


Clause 0.3.2 


m 




NOTE 1 : The P-CSCF has to send a SUBSCRIBE request to the home domain in which the user's public user identity 
resides upon receipt of a 200OK response to the first initial REGISTER request. 

NOTE 2: The P-CSCF has to send a SUBSCRIBE request to the home domain in which the user's public user identity 
resides upon receipt of a 2xx response to a registration that contained an empty P-Debug-ID header field. 

NOTE 3: The P-CSCF is informed of additional public user identities by the registrar via NOTIFY requests. 

NOTE 4: See also PICS item A.3/8. 

o.n At least one of these capabilities shall be supported. 

C.I 0, if A.3/25.4.2.2 is supported, else n/a 

C.2 0, if A.3/31 is supported, else n/a 

C.3 m, if A.3/35 is supported, else n/a 
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A.5.2.2 P-CSCF header handling 



Table A.4: P-CSCF Header Handling 



Item 


Header handling: 
Does the implementation support... 


Reference 


Status 


Support 


1 


Insertion or modification of the Resource-Priority 
header to give priority to emergency or priority 
transactions? 


Clause 5.2.1, 
RFC 4412 [6] 


C.I 




2 


The Path header in REGISTER request and 
related 200OK response messages? 


Clause 5.2.1 


m 




3 


The Service-Route header in 200OK response 
messages to REGISTER requests? 


Clause 5.2.1 


m 




4.1 


Removal of the P-Charging-Function-Addresses 
header from requests and responses to be sent to 
the UE? 


Clause 5.2.1 


m 




4.2 


Removal of the P-Charging-Vector header from 
requests and responses to be sent to the UE? 


Clause 5.2.1 


m 




5.1.1 


Removal of the P-Charging-Function-Addresses 
header from requests and responses received 
from the UE? 


Clause 5.2.1, 
numbered item 1 


m 




5.1.2 


Insertion of saved P-Charging-Function- 
Addresses header into requests and responses 
from the UE to be forwarded? 


Clause 5.2.1 
numbered item 2 







5.2.1 


Removal of the P-Charging-Vector header from 
requests and responses received from the UE? 


Clause 5.2.1 
numbered item 1 


m 




5.2.2 


Insertion of saved P-Charging-Vector header into 
requests and responses from the UE to be 
forwarded? 


Clause 5.2.1 
numbered item 2 







5.3.1 


Removal of the P-Access-Networl< header with 
"network provided" parameter? 


Clause 5.2.1 
numbered item 3 


m 




5.3.2 


Insertion of the P-Access-Network header with 
parameters set to the appropriate (access 
technology dependent) values? 


Clause 5.2.1 
numbered item 4 







6 


Removal of the P-Media-Authorization header 
from requests and responses to be sent to the UE? 


Clause 5.2.1 


m 




7 


Removal, insertion and modification of the 
P-Early-IUIedia header? 


Clause 5.2.1, 
RFC 5009 [7] 







C.I 0, if A.3/1 1 is supported, else n/a 



A.5.3 l-CSCF Role 

The tables provided in this clause need only to be completed for I-CSCF implementations, where item A.2/2 above is 
supported. 

A.5.3. 1 l-CSCF Capabilities 

Table A.5: l-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


The proxy role with IIVIS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.3 


m 




1.2 


The UA role when providing server functionality to 
return a final response? 


Clause 4.1 







2 


Signalling security using (Clause 4.2B.1) ... 


2.1 


IMS AKA plus IPsec ESP? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
clause 6 


m 





£75/ 



21 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


2.2 


SIP digest plus check of IP association? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex S 







2.3 


SIP digest plus Proxy Authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex N 







2.4 


SIP digest with TLS? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex N, 







2.5 


NASS-IIVIS bundled authentication? 


Clause 4.2B.1, 
table 4-1 , 
TS 133 203 [8] 
annex R 







2.6 


GPRS-IMS-Bundled authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex S 







2.7 


Trusted node authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex U 







3.1 


The loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




3.2 


Interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] 
Clauses 12.2.1.1, 
16.4 


m 




4 


Procedures related to charging? 


Clause 4.5 


m 




5 


Tracing of signalling? 


Clause 4.8 







6 


Procedures related to overlap sending? 


Clause 4.9 


m 




l-CSCF specific application usage of SIP (clause 5.3) 


7.1 


Procedures that apply on receipt of a REGISTER 
request? (see note 1) 


Clause 5.3.1.2 


m 




7.2 


Procedures that apply on receipt of a user 
registration status query response? (see note 2) 


Clause 5.3.1.2 first 
and second 
numbered list 


m 




7.2.1 


Insertion of the Redirect-Host AVP into the 
P-User-Database header of the REGISTER 
request to be sent to the S-CSCF? 


Clause 5.3.1.2 first 
2), second 3) 







7.3.1 


Procedures that apply in case the user registration 
status query procedure fails? 


Clause 5.3.1.3 


m 




7.3.2 


Procedures that apply on receipt of no response or 
a response other than 200OK from the S-CSCF? 


Clause 5.3.1.3 


m 




8.1 


Stateful proxy behaviour for initial requests? 


Clause 5.3.2.1 first 
sentence 


0.1 




8.2 


Stateless proxy behaviour for initial requests? 


Clause 5.3.2.1 
complement of first 
sentence 


0.1 




8.3 


Handling of initial requests not containing the "orig" 
parameter in the topmost Route header? 


Clause 5.3.2.1 


m 




8.3.1 


Application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.3.2.1 







8.3.2 


Insertion of the Redirect-Host AVP into the 
P-User-Database header of INVITE requests to 
be forwarded to the S-CSCF? 


Clause 5.3.2.1 
second 3) 







8.4 


Originating procedures for requests containing the 
"orig" parameter in the topmost Route header? 


Clause 5.3.2.1A 


m 




8.4.1 


Application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.3.2.1A 







8.4.2 


Insertion of the Redirect-Host AVP into the 
P-User-Database header of INVITE requests to 
be forwarded to the S-CSCF? 


Clause 5.3.2.1A 
first 3) 
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Item 



Major capability: 
Does the implementation support.. 



Reference 



Status 



Support 



8.5 



Abnormal cases related to Initial requests (clause 5.3.2.2) 



8.5.1 



Procedures for successful user location query 
when the S-CSCF cannot be contacted? 



Clause 5.3.2.2 



m 



8.5.2 



Procedures for unsuccessful outcome of request 
processing? 



Clause 5.3.2.2 



m 



Additional routeing capabilities in support of transit and interconnection traffics in IM CN subsystem (Annex I) 
9 [Additional routeing capabilities? [Annex I | o | 



NOTE 1 : 



NOTE 2: 



o.n 



The l-CSCF has to start the user registration status query procedure on receipt of the REGISTER request 

from the P-CSCF. The l-CSCF shall behave as a stateful proxy. 

If the user registration status query procedure succeeds, the l-CSCF has to forward the REGISTER request 

to the S-CSCF. The 200OK response from the S-CSCF has to be proxied to the P-CSCF. 

At least one of these capabilities shall be supported. 



A.5.4 S-CSCF Role 

The tables provided in this clause need only to be completed for S-CSCF implementations, where item A.2/3 above is 
supported. 

A.5.4. 1 S-CSCF Capabilities 

Table A.6: S-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


The proxy role with IIVIS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.4 


m 




1.2 


The proxy role with IIVIS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.3 


m 




2 


The UA role with IMS related exceptions and 
additional capabilities? (see note 1) 


Clauses 4.1, 5.4 


m 




3 


Signalling security using (Clause 4.2B.1 ) ... 


3.1 


IMS AKA plus IPsec ESP? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
clause 6 


m 




3.2 


SIP digest plus check of IP association? 


Clause 4.2B.1, 
table 4-1, 
TS 1 33 203 [8] 
annex S 







3.3 


SIP digest plus Proxy Authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 1 33 203 [8] 
annex N 







3.4 


SIP digest with TLS? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex N, 







3.5 


NASS-IMS bundled authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 1 33 203 [8] 
annex R 







3.6 


GPRS-IMS-Bundled authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 1 33 203 [8] 
annex S 







3.7 


Trusted node authentication? 


Clause 4.2B.1, 
table 4-1, 
TS 133 203 [8] 
annex U 







4.1 


The loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 





£75/ 



23 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


4.2 


interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] 
Clauses 12.2.1.1, 
16.4 


m 




5 


Procedures related to charging? 


Clause 4.5 


m 




6 


Procedures related to emergency services? 


Clauses 4.7, 5.4.8 


m 




7 


Tracing of signalling? 


Clause 4.8 







8 


Procedures related to overlap sending? 


Clause 4.9 


m 




9 


Priority mechanisms? 


Clause 4.11 


m 




S-CSCF specific appiication usage of SIP (clause 5. 4) 


10 


Provision of priority to emergency registrations and 
calls? 


Clauses 5.4.0, 
5.4.1.1 


m 




Registration general (clause 5.4. 1) 


11 


Selection of the authentication mechanism based 
on the contents of the REGISTER request 
(Authorization header and/or P-Access-Network- 
Info header)? 


Clause 5.4.1.1 


m 




Unprotected REGISTER and challenges (clause 5.4. 1.2. 1) 


11.1 


Procedures that apply on receipt of an unprotected 
REGISTER request for an already registered 
public user identity? 


Clause 5.4.1.2.1 first 
numbered list 


m 




11.2 


Procedures that apply on receipt of an unprotected 
REGISTER request for a not yet registered public 
user identity? 


Clause 5.4.1.2.1 
second numbered 
list 


m 




12.1 


Provision of challenges with IMS AKA as security 
mechanism in the 401 response? 


Clause 5.4.1. 2.1 A 


m 




12.2 


Provision of challenges with SIP digest as security 
mechanism in the 401 response? 


Clause 5.4.1. 2.1 B 


C.1 




12.3 


Provision of challenges with SIP digest with TLS 
as security mechanism in the 401 response? 


Clause 5.4.1. 2.1 C 


C.2 




13.1 


Procedures for initial registration and user-initiated 
reregistration for NASS-IMS bundled 
authentication? 


Clause 5.4.1. 2.1 D 


C.3 




13.2 


Procedures for initial registration and user-initiated 
reregistration for GPRS-IMS bundled 
authentication? 


Clause 5.4.1. 2.1 E 


C.4 




Protected REGISTER (clause 5.4. 1.2.2) 


14.1 


Procedures that apply on receipt of a protected 
REGISTER request when IMS AKA as security 
mechanism applies? 


Clauses 5.4.1.2.2, 
5.4.1. 2.2F 


m 




14.2 


Procedures that apply on receipt of a protected 
REGISTER request when SIP digest as security 
mechanism applies? 


Clauses 5.4.1. 2.2A, 
5.4.1. 2.2F 


c.1 




14.3 


Procedures that apply on receipt of a protected 
REGISTER request when SIP digest with TLS as 
security mechanism applies? 


Clauses 5.4.1. 2.2B, 
5.4.1. 2.2F 


c.2 




14.4 


Procedures that apply on receipt of a protected 
REGISTER request for which authentication is 
already performed? 


Clauses 5.4.1. 2.2E, 
5.4.1. 2.2F 


m 




Registration abnormal cases (clause 5.4. 1.2.3) 


15.1 


General procedures for handling of abnormal 
cases related to initial registration and 
user-initiated re-registration? 


Clause 5.4.1.2.3 


m 




15.2 


Procedures for handling of abnormal cases related 
to initial registration and user-initiated 
re-registration when IMS AKA as security 
mechanism applies? 


Clause 5.4.1. 2.3A 


m 




15.2.1 


On receipt of a REGISTER request, indicating that the SON was deemed to be out of range by the UE 
(clause 5.4.1.2.3A, second dashed list) ... 


15.2.1.1 


Sends a 401 response? 


Clause 5.4.1. 2.3A, 
second dashed list, 
first dash 


0.1 




15.2.1.2 


Sends a 403 response? 


Clause 5.4.1. 2.3A, 
second dashed list, 
second dash 


0.1 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


15.3 


Procedures for handling of abnormal cases related 
to initial registration and user-initiated 
re-registration when SIP digest as security 
mechanism applies? 


Clause 5.4.1. 2.3B 


C.1 




15.3.1 


On receipt of a REGISTER request, that contains the authentication challenge response from the UE 
that does not match with the expected REGISTER request (clause 5.4.1 .2.3B, first dashed list) ... 


15.3.1.1 


Sends a 403 response? 


Clause 5.4.1. 2.3B, 
first dashed list, 
first dash 


0.2 




15.3.1.2 


Sends a 401 response? 


Clause 5.4.1. 2.3B, 
first dashed list, 
second dash 


0.2 




15.4 


Procedures for handling of abnormal cases related 
to initial registration and user-initiated 
re-registration when SIP digest with TLS as 
security mechanism applies? 


Clauses 5.4.1. 2.3C 


C.2 




15.4.1 


On receipt of a REGISTER request, that contains the authentication challenge response from the UE 
that does not match with the expected REGISTER request (clause 5.4.1 .2.3B, first dashed list) ... 


15.4.1.1 


Sends a 403 response? 


Clause 5.4.1. 2.3B, 
first dashed list, 
first dash 


0.3 




15.4.1.2 


Sends a 401 response? 


Clause 5.4.1. 2.3B, 
first dashed list, 
second dash 


0.3 




Deregistration, re-authentication, registration status notification, service profiie updates (ciauses 5.1.4-5.1.8) 


16.1 


Procedures for handling of normal cases related to 
user-initiated deregistration? 


Clause 5.4.1.4.1 


m 




16.2 


Procedures for handling of abnormal cases related 
to user-initiated deregistration when IMS AKA as 
security mechanism applies? 


Clause 5.4.1.4.2 


m 




16.3 


Procedures for handling of abnormal cases related 
to user-initiated deregistration when SIP digest as 
security mechanism applies? 


Clause 5.4.1.4.3 


c.1 




16.4 


Procedures for handling of abnormal cases related 
to user-initiated deregistration when SIP digest 
with TLS as security mechanism applies? 


Clause 5.4.1.4.4 


c.2 




17 


Network-initiated deregistration? 


Clause 5.4.1.5 


m 




18 


Network-initiated re-authentication? 


Clause 5.4.1.6 


m 




19 


Notification of AS about registration status? 


Clauses 5.4.1.7, 
5.4.1. 7A 


m 




19.1 


When building the To header of the REGISTER request to the AS (clause 5.4.1.7 c)) ... 


19.1.2 


Insertion of a public user identity as contained in 
the REGISTER request received from the UE? 


Clause 5.4.1.7 c) 


0.4 




19.1.2 


Insertion of an implicitly registered public user 
identities from the service profile? 


Clause 5.4.1.7 c) 


0.4 




20 


Service profile updates? 


Clause 5.4.1.8 


m 




20.1 


When receiving a service profile modifying Push-Profile-Request (clause 5.4.1.8, item 4)) ... 


20.1.1 


Procedures for notification of the reg-event 
subscribers about the registration state? 


Clause 5.4.1.8, 
item 4) first dash 


0.5 




20.1.2 


Shortening the life time of the current registration? 


Clause 5.4.1.8, 
item 4) second dash 


0.5 




Subscription and notification (clause 5.4.2) 


21 


Subscriptions to S-GSGF events? 


Clause 5.4.2.1 


m 




21.1 


Procedures that apply on receipt of SUBSCRIBE 
request related to event providing registration 
state? 


Clause 5.4.2.1.1 


m 




21.2 


Transmission of notifications about the event 
providing registration state? 


Clause 5.4.2.1.2 


m 




21.3 


Procedures that apply on receipt of SUBSCRIBE 
request related to event providing debug state? 


Clause 5.4.2.1.3 


m 




21.4 


Transmission of notifications about the debug 
configuration? 


Clause 5.4.2.1.4 


m 




22 


Other subscriptions? 


Clause 5.4.2.2 
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Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


Handling of requests for all dialogs and standalone transactions (clause 5.4.3) 


23.1 


General handling of requests initiated by the 
served user? 


Clause 5.4.3.2, 
before first 
numbered list 


m 




23.2 


Handling of the receipt of initial requests for a 
dialog or a standalone transaction from the served 
user? 


Clause 5.4.3.2, first 
numbered list 


m 




23.3 


Handling of the receipt of initial requests for a 
dialog or a standalone transaction from an AS 
acting on behalf of an unregistered user? 


Clause 5.4.3.2, 
second numbered 
list 


m 




23.4 


Rejection with retention procedure of initial 
requests for a dialog or a standalone transaction 
from the served user (without or with untrusted 
profile) upon failure of profile retrieval? 


Clause 5.4.3.2 third 
numbered list 







23.5 


Handling of the responses (or the absence of 
responses) to initial requests for a dialog or a 
standalone transaction? 


Clause 5.4.3.2, all 
text between third 
and fifth numbered 
list 


m 




23.6 


Handling of the receipt of target refresh requests 
from the served user? 


Clause 5.4.3.2, fifth 
numbered list 


m 




23.7 


Handling of the Ixx and 2xx responses to target 
refresh requests? 


Clause 5.4.3.2, sixth 
and seventh 
numbered list 


m 




24.1 


General handling of requests terminated by the 
served user? 


Clause 5.4.3.3, 
before first 
numbered list 


m 




24.2 


Handling of the receipt of initial requests for a 
dialog or a standalone transaction for a registered 
user? 


Clause 5.4.3.3, first 
numbered list 


m 




24.3 


Specific handling of the responses (or the absence 
of responses) to initial requests for a registered 
user? 


Clause 5.4.3.3, all 
text between first 
and third numbered 
list 


m 




24.4 


Handling of the receipt of initial requests for a 
dialog or a standalone transaction for an 
unregistered user? 


Clause 5.4.3.3, third 
numbered list 


m 




24.5 


General handling of the responses to initial 
requests for a registered or unregistered user? 


Clause 5.4.3.3, 
fourth numbered list 


m 




24.6 


General handling of the responses to requests for 
standalone transaction for a registered or 
unregistered user? 


Clause 5.4.3.3, fifth 
and sixth numbered 
list 


m 




24.7 


Handling of the receipt of target refresh requests 
for the served user? 


Clause 5.4.3.3, 
seventh numbered 
list 


m 




24.8 


General handling of the Ixx and 2xx responses to 
target refresh requests for a registered or 
unregistered user? 


Clause 5.4.3.3, 
eighth numbered list 


m 




24.6 


Handling of the receipt of subsequent requests 
(other than target refresh) for the served user? 


Clause 5.4.3.3, ninth 
numbered list 


m 




24.7 


Handling of the Ixx and 2xx responses to 
subsequent requests? 


Clause 5.4.3.3, tenth 
numbered list 


m 




25 


Encoding of the original dialog identifier? 


Clause 5.4.3.4 


m 




SIP digest authientlcatlon procedures 


26 


General procedures for SIP digest authentication 
for all requests other than REGISTER? 


Clause 5.4.3.6.1 


C.5 




26.1 


Rejection of requests with a 400 response in case 
of mismatching public user identity? 


Clause 5.4.3.6.1, 
first numbered list, 
item 2) 


C.6 




26.2 


In case of receipt of a mismatching challenge response (clause 5.4.3.6.1 , second numbered list) ... 
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Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


26.2.1 


Rechallenging of requests with a 407 response? 


Clause 5.4.3.6.1, 
second numbered 
list, item 1) 


C.7 




26.2.2 


Rejection of requests with a 403 response? 


Clause 5.4.3.6.1, 
second numbered 
list, item 2) 


C.7 




26.2.3 


Rejection of requests without a response? 


Clause 5.4.3.6.1, 
second numbered 
list, item 3) 


c.7 




27 


Procedures for abnormal cases within SIP digest 
authentication for all requests other than 
REGISTER? 


Clause 5.4.3.6.2 


m 




Call initiation (clause 5.4.4) 


28.1 


Additional requirements for INVITE requests from 
the served user? 


Clause 5.4.4.1 


m 




28.2 


Additional requirements for INVITE requests for 
the served user? 


Clause 5.4.4.1 


m 




28.2.1 


Application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.4.4.1 







28.2.2 


Examination of the contents of the SDP offer within 
the INVITE requests for the served user? 


Clause 5.4.4.1, 
alphabetic list 







28.2.2.1 


On detection of an unsupported IP address type (clause 5.4.4.1, dashed list)... 


28.2.2.1.1 


Rejection of the requests with a 305 response 
towards the l-CSCF? 


Clause 5.4.4.1, 
first dash 


C.8 




28.2.2.1.2 


Acceptance and forwarding of the request towards 
the IBCF? 


Clause 5.4.4.1, 
second dash 


C.8 




29.1 


Additional requirements for subsequent requests 
(UE-originating case)? 


Clause 5.4.4.2.1 


m 




29.1.1 


Insertion of previously saved values into the 
P-Charging-Vector header and 
P-Charging-Function-Addresses header of 

requests and responses (other than ACK and 
CANCEL)? 


Clause 5.4.4.2.1, 
third paragraph 







29.2 


Additional requirements for subsequent requests 
for the served user (UE-terminating case)? 


Clause 5.4.4.2.2 


m 




29.2.1 


Insertion of previously saved values into the 
P-Charging-Vector header and 
P-Charging-Function-Addresses header of 

requests and responses (other than ACK and 
CANCEL)? 


Clause 5.4.4.2.2, 
third paragraph 







Call release (clause 5.4.5) 


30.1 


S-CSCF initiated call release (clause 5.4.5.1 ) ... 


30.1.1 


Of sessions currently being established? 


Clause 5.4.5.1.1 


m 




30.1.2 


Of existing sessions? 


Clause 5.4.5.1.2 


m 




30.1.3 


Of existing dialogs due to registration expiration? 


Clause 5.4.5.1. 2A 


m 




30.1.4 


Including abnormal cases? 


Clause 5.4.5.1.3 


m 




30.2 


Call release initiated by other entities? 


Clause 5.4.5.2 


m 




30.3 


Call release due to session expiry? 


Clause 5.4.5.3 


m 




Call-related requests (clause 5.4.6) 


31.1 


Additional requirements for RelNVITE and 
UPDATE requests (UE-originating case)? 


Clause 5.4.6.1.2 


m 




31.2 


Additional requirements for RelNVITE and 
UPDATE requests for the served user 
(UE-terminating case)? 


Clause 5.4.6.1.3 


m 




GRUU management (clause 5.4. 7 A) 


32 


GRUU management? 


Clause 5.4.7A 


m 




32.1 


Construction of public GRUUs? 


Clause 5.4.7A.2 


m 




32.2 


Construction of temporary GRUUs? 


Clause 5.4.7A.3 


m 




32.2.1 


Temporary GRUUs without the need for extra 
states? 


Clause 5.4.7A.3 


0.8 




32.2.2 


Stateful representation of temporary GRUUs? 


Clause 5.4.7A.3 


0.8 




32.3 


GRUU recognition and validity checking? 


Clause 5.4.7A.4 


m 





£75/ 



27 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


Emergency service (clause 5.4.8) (see note 2) 


33.1 


Additional procedures for requests for initial 
emergency registration or user-initiated emergency 
reregistration? 


Clause 5.4.8.2 


m 




33.2 


Rejection of user-initiated emergency 
deregistration requests? 


Clause 5.4.8.3 






S-CSCF specific application usage of SDP (clause 6.3) 


34.1 


Handling of requests including SDP offers? 


Clause 6.3 


m 




34.1.1 


Rejection of requests including encrypted SDP 
offers? 


Clause 6.3, first 
paragraph 







34.2 


Handling of responses (other than 200OK) 
including SDP offers? 


Clause 6.2, second 
paragraph 


m 




34.2.1 


Rejection of requests following non-200OK 
responses including encrypted SDP offers? 


Clause 6.3, second 
paragraph 







34.3 


Handling of 200OK responses including SDP 
offers? 


Clause 6.2, third 
paragraph 


m 




34.3.1 


Session termination on receipt of encrypted SDP 
offers in 200OK responses? 


Clause 6.2, third 
paragraph 







Additional routeing capabilities in support of transit and interconnection traffics in IM CN subsystem (Annex 1) 


35 Additional routeing capabilities? Annex 1 o 


IP-Connectivity Access Network specific concepts when using cdma2000® packet data subsystem to access IM CN 
subsystem (Annex M) 


36 


Additional procedures for notification of the AS 
about the registration status? 


Clause M.3.3.1 


m 




IP-Connectivity Access Network specific concepts when using the EPC via cdma2000® HRPD to access IM CN 
subsystem (Annex 0) 


37 


Additional procedures for notification of the AS 
about the registration status? 


Clauses 0.3.3, 
M.3.3.1 


m 




NOTE 1 : The S-CSCF shall provide the UA role when acting as registrar or notifier of event information, when 
providing a messaging mechanism by sending the MESSAGE method and when performing S-CSCF 
initiated dialog release. 

NOTE 2: See also PICS item A.6/6. 

o.n At least one of these capabilities shall be supported. 

C.I m, if A.6/3.2 or A.6/3.3 is supported, else o 

C.2 m, if A.6/3.4 is supported, else o 

C.3 m, if A.6/3.5 is supported, else o 

C.4 m, if A.6/3.6 is supported, else o 

C.5 0, if 6/3.2 or A.6/3.3 or A.6/3.4 is supported, else n/a 

C.6 0, if 6/3.26 is supported, else n/a 

C.7 0.6, if 6/3.26 is supported, else n/a 

C.8 0.7, if A.6/28.2.2 is supported, else n/a 



A.5.4.2 S-CSCF header handling 



Table A.7: S-CSCF Header Handling 



Item 


Header handling: 
Does the implementation support... 


Reference 


Status 


Support 


1 


The Path header in REGISTER request and 
related 200OK response messages? 


Clause 5.4.1.1 


m 




2 


The Service-Route header in 200OK response 
messages to REGISTER requests? 


Clause 5.4.1.1 


m 




3 


The Require header? 


Clause 5.4.1.1 


m 




4 


The Supported header? 


Clause 5.4.1.1 


m 
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A.5.5 IBCF Role 

The tables provided in this clause need only to be completed for IBCF implementations, where item A.2/4 above is 
supported. 



A.5.5. 1 IBCF Capabilities 



Table A.8: IBCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1 


The proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.10 


m 




2 


Provision of application level gateway 
functionality? 


Clause 4.1 







3 


Provision of screening functionality? 


Clause 4.1 







4.1 


The UA role with IIVIS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.10 


C.I 




4.2 


The UA role with IIVIS related exceptions and 
additional capabilities to SDP? 


Clauses 4.1, 6.7 


C.2 




5.1 


The loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




5.2 


Interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] and 
clauses 12.2.1.1, 
16.4 


m 




6 


Procedures related to emergency services? 


Clause 4.7 


m 




7 


Tracing of signalling? 


Clause 4.8 







8 


Priority mechanisms? 


Clause 4.11 


m 




IBCF specific application usage of SIP (clause 5.10) 


9 


Procedures when acting as exit point (clause 5.10.2) ... 


9.1 


Procedures that apply on receipt of a REGISTER 
request when acting as exit point? 


Clause 5.10.2.1 


m 




9.2 


Provision of priority over other transactions or 
dialogs based on the Resource-Priority header for 
all request types when acting as exit point? 


Clause 5.10.2.1A 


C.3 




9.3 


Procedures that apply on receipt of initial requests, 
standalone requests (other than REGISTER) and 
unknown method requests when acting as exit 
point? 


Clause 5.10.2.2 


m 




9.3.1 


Application of periodic session refreshment on 
receipt of INVITE requests when acting as exit 
point? 


Clause 5.10.2.2 







9.4 


Procedures that apply on receipt of a responses to 
initial requests when acting as exit point? 


Clause 5.10.2.2 


m 




9.5 


Procedures that apply on receipt of subsequent 
requests when acting as exit point? 


Clause 5.10.2.3 


m 




9.6 


Procedures that apply on receipt of responses to 
subsequent requests when acting as exit point? 


Clause 5.10.2.3 


m 




9.7 


Provision of transport plane control functionality 
when acting as exit point? 


Clause 5.10.2.4 







9.7.1 


IBCF-initiated call release in case of receipt of an 
indication of a transport plane related error when 
acting as exit point? 


Clause 5.10.2.4 


C.4 




10 


Procedures when acting as entry point (clause 5.10.3) ... 


10.1 


Procedures that apply on receipt of a REGISTER 
request when acting as entry point? 


Clause 5.10.3.1 


m 




10.2.1 


Provision of priority over other transactions or 
dialogs based on the Resource-Priority header for 
all request types when acting as entry point? 


Clause 5.10.3.1A 


c.3 




10.2.1 


Provision of priority over other transactions or 
dialogs based on the alternative mechanism to 
recognize the need for priority treatment for all 
request types when acting as entry point? 


Clause 5.10.3.1A 


c.3 





£75/ 



29 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



Item 


Major capability: 
Does the implementation support- 


Reference 


Status 


Support 


10.3 


Procedures that apply on receipt of initial requests, 
standalone requests (other than REGISTER) and 
unknown method requests when acting as entry 
point? 


Clause 5.10.3.2 


m 




10.3.1 


Application of periodic session refreshment on 
receipt of INVITE requests when acting as entry 
point? 


Clause 5.10.3.2 







10.4 


Procedures that apply on receipt responses to 
initial requests when acting as entry point? 


Clause 5.10.3.2 


m 




10.5 


Procedures that apply on receipt of subsequent 
requests when acting as entry point? 


Clause 5.10.2.3 


m 




10.6 


Procedures that apply on receipt of responses to 
subsequent requests when acting as entry point? 


Clause 5.10.3.3 


m 




10.7 


Provision of transport plane control functionality? 


Clause 5.10.3.4 







10.7.1 


IBCF-lnitiated call release in case of receipt of an 
indication of a transport plane related error? 


Clause 5.10.3.4 


c.5 




11 


Procedures for network topology hiding? 


Clause 5.10.4 


m 




11.1 


Inclusion of a direction identifier to an 
IBCF-lnserted SIP URI? 


Clauses 5.10.4.1, 
5.10.2.1 and 
5.10.3.1 







11.2 


Encryption for network topology hiding? 


Clause 5.10.4.2 


m 




11.3 


Decryption for network topology hiding? 


Clause 5.10.4.3 


m 




12 


IIVIS-ALG functionality? 


Clauses 5.10.5, 6.7 







13 


Screening of SIP signalling? 


Clause 5.10.6 


m 




13.1 


B2BUA functionality when performing screening of 
the SIP signalling? 


Clauses 5.10.6.1, 
5.10.5 







13.2 


Omission or modification of received SIP headers 
prior to forwarding SIP messages? (see note) 


Clause 5.10.6.2 







13.3 


Omission or modification of received SDP bodies 
prior to forwarding SIP messages? 


Clause 5.10.6.3 







14 


Media transcoding control? 


Clause 5.10.7 







14.1 


Addition one or more codecs at the end of the 
codec list in the selected media of request before 
forwarding the request to the answerer? 


Clause 5.10.7.1 


c.6 




14.2 


Inspection and treatment of codec entries in 
responses received from the answerer? 


Clause 5.10.7.1 


c.7 




15 


Privacy protection at the trust domain boundary? 


Clause 5.10.8 


m 




16 


procedures for the support of ICE in IIVIS-ALG 
within the IBGF? 


Clause 6.7.1.2 


c.8 




16.1 


Procedures for the support of ICE in IIVIS-ALG 
within the IBCF? 


Clause 6.7.1.2.1 


c.9 




16.1.1 


Procedures when no TrGW is inserted? 


Clause 6.7.1.2.1 


c.9 




16.1.2 


Procedures when a TrGW is attached? 


Clause 6.7.1.2.1 


c.9 




16.2 


IMS-ALG in IBCF full ICE procedures for UDP 
based streams? 


Clause 6.7.1.2.2 


c.9 




16.3 


IIVIS-ALG in IBCF lite ICE procedures for UDP 
based streams? 


Clause 6.7.1.2.3 


c.9 




16.4 


IIVIS-ALG in IBCF ICE procedures for TCP based 
streams? 


Clause 6.7.1.2.4 


c.9 




Additional routeing capabilities in support of transit and interconnection traffics in IM CN subsystem (Annex 1) 


17 Additional routeing capabilities? Annex! o 


NOTE: The modification of the following headers is discouraged by TS 124 229 [1]: Authorization, 
WWW-Autlienticate, Path and Service-Route headers. 

C.1 m, if A.8/2 is supported, else 
C.2 m, if A.8/2 is supported, else n/a 
C.3 m, if A.8/8 is supported, else o 
C.4 0, if A.8/9.7 is supported, else n/a 
C.5 0, if A.8/1 0.7 is supported, else n/a 
C.6 0, If A.8/1 4 is supported, else n/a 
C.7 m, if A.8/1 4 is supported, else n/a 
C.8 0, if A.8/1 2 is supported, else n/a 
C.9 0, if A.8/1 6.1 is supported, else n/a 



£75/ 



30 



ETSI TS 102 790-1 V2.1.1 (2012-11) 



A.5.6 E-CSCF Role 

The tables provided in this clause need only to be completed for E-CSCF implementations, where item A.2/5 above is 
supported. 

A.5.6. 1 E-CSCF Capabilities 

Table A.9: E-CSCF Capabilities 



Item 


Major capability: 
Does the implementation support... 


Reference 


Status 


Support 


General Capabilities (clause 4) 


1.1 


The proxy role with IMS related exceptions and 
additional capabilities to SIP? 


Clauses 4.1, 5.11 


m 




1.2 


The UA role when providing server functionality to 
return a final response? 


Clause 4.1 


m 




2.1 


The loose routeing policy? 


Clause 4.3, 
RFC 3261 [2] 


m 




2.2 


Interoperability with strict routers? 


Clause 4.3, 
RFC 3261 [2] and 
clauses 12.2.1.1, 
16.4 


m 




3 


Procedures related to charging? 


Clause 4.5 


m 




6 


Procedures related to emergency services? 


Clauses 4.7, 5.11 


m 




7 


Tracing of signalling? 


Clause 4.8 







E-CSCF specific application usage of SIP (clause 5.11) 


8 


General procedures related to emergency 
services? 


Clause 5.11.1 


m 




8.1 


Acceptance and onwards routeing of requests 
(initial requests for a dialog, for a standalone 
transaction, or for an unknown method) for 
emergency services? (see note) 


Clause 5.1 1.2 


m 




8.2 


Rejection of requests for non-emergency services? 
(see note) 


Clause 5.1 1.2 


m 




8.3 


Insertion of previously saved values into the 
P-Charging-Vector and P-Charging-Function 

header of requests and responses (other than 
CANCEL and ACK) to be forwarded? 


Clause 5.1 1.2 







8.4 


Procedures that apply on receipt of responses to 
requests (initial requests for a dialog, for a 
standalone transaction, or for an unknown method) 
for emergency services? 


Clause 5.1 1.2 


m 




8.5 


Application of periodic session refreshment on 
receipt of INVITE requests? 


Clause 5.11.2 







9 


Emergency services procedures that require the 
use of an LRF? 


Clause 5.11.3 


m 




10 


Procedures for subscriptions to E-CSCF events? 


Clause 5.11.4 


m 




10.1 


Processing of subscriptions to the event providing 
dialog state? 


Clause 5.1 1.4.1 


m 




10.2 


Provision of notifications about dialog states? 


Clause 5.1 1.4.2 


m 




NOTE: Request for emergency services contain an URN with a top-level service type of "sos". 
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